The Internet has seen explosive growth primarily fueled by the introduction and widespread use of web browsers that enable access to networked servers via a simple, graphical, user interface (GUI). Web browsers support hypertext documents, often referred to as web pages, such as hypertext markup language (HTML) and allow a user to load these documents remotely from a server via local area networks (LANs) and wide area networks (WANs).
Servers like the IBM eServer i-Series and p-Series include a web server application to execute web applications like common gateway interface (CGI) applications in response to requests by a user. More specifically, the web server interacts with the user's web browser to facilitate communication between the server and the user using a hypertext transport protocol (HTTP). The web server passes data between the browser and web applications of the server and finds, loads, and unloads web applications in response to communications from the user via the browser.
HTTP, however, is a stateless protocol so each request from an HTTP client to an HTTP server is considered a new request and no state is maintained between the requests. Since the most common interactions between a user and a server require multiple, related requests, the server creates a session to track the related requests so the server can react properly to a user's communication. HTTP cookies and/or uniform resource locators (URLs) typically facilitate tracking of the state of the session on the user's side. Cookies are created by a web application and include data such as a range of URLs for which the cookie is valid. The cookie is then stored on a user's computer via the web browser and returned to the server when the browser encounters the same URLs. URLs can be used in a similar manner by incorporating session data in a URL so a parsing routine can find the session data.
A session management application on the server typically remains resident in memory, monitoring interactions between a user and the web applications to track the activities of a user via the cookies or URLs. For example, a user may cause a CGI to be executed on the server to perform a product search in a database of an on-line store. When the user causes another CGI to execute to add the results of the product search to a “shopping cart”, the session management application creates a session to track items added to the shopping cart.
When the user decides to check out, the session management application creates a secure session, or login session, to track sensitive information like payment, billing, and shipping information. In particular, by pressing a “checkout” button, the user implements a login CGI that authenticates the user's identity by verifying, e.g., the user's name and password. The session management application must then remember the sensitive information provided by the user to facilitate the checkout process and to avoid the security risks inherent to passing the sensitive information back and forth between the server and web browser via cookies or URLs.
Current solutions for remembering the login session involve maintaining the session management application resident in memory and storing the sensitive information in memory allocated for the session management application. The session management application can then pass the sensitive information to other applications as necessary to implement the checkout process. Other solutions conserve memory resources in the server by storing the sensitive information in a database application, e.g., on a hard drive. The session management application creates a session identification and transmits a cookie with the session identification to the user for identifying the login session. When the user accesses a web application related to the login session, the cookie is transmitted to the session management application, and the session management application accesses the database application via an application program interface (API) to verify the user's login information.
The adaptability associated with such web application architecture has inspired the design of embedded applications for many current servers. In particular, servers such as IBM eServer i-Series and p-Series offer access to system management and configuration applications, referred to as service processor menus, via web browsers. Thus, a user such as an administrator, customer, and/or customer engineer can implement major configuration and system setting changes like managing the boot and shutdown sequences for the server by directing communications to a URL for the embedded system via a web browser.
Similar to the access of login sessions via web applications, embedded systems may require the user to login and privilege levels associated with the user's login facilitate access to various applications, e.g., service processor menus or functions of the service processor menus. For instance, the customer engineer may have the highest level of access since the function of the customer engineer is typically to identify and repair problems associated with the server. The administrator and customer may have lower privilege levels to provide access to system settings and configurations associated with authorizing and managing users, and customizing the server's functionality for the customer.
Unlike access to login sessions via web applications, embedded systems do not typically anticipate thousands or hundreds of thousands of concurrent users. Embedded systems may anticipate up to, e.g., a dozen concurrent users, and have relatively limited resources to track user login sessions. Since maintaining the web server, session management application as well as login and session information resident in memory consumes a significant amount of the limited resources available to embedded systems, current solutions are impractical.
The other solutions that involve maintaining the web server, session management application and session identity resident in memory while storing the sensitive information and session state information within a database application, are slow as well as impractical. In particular, the session management application must interface with an API for the database application through bridges, secondary busses, and input-output (I/O) drivers to access the sensitive information, compounding the latency involved with each communication that requires user authentication. Further, when considering that only a dozen users may be accessing login sessions concurrently, the use of a database application to store sensitive information is a significant waste of server resources.